Traditionally, one of the weakest and most overlooked areas of software design and development is error reporting and recovery. Prior art computer-aided design systems typically provide multiple error and/or warning messages as the result of a single fault. Multiple messages result from architectural structures wherein warning/error messages are passed through multiple architectural levels from the level where the fault occurs to the level where the warning/error messages are presented to the user.
FIG. 1 is a conceptual illustration of prior art of function calls and returns. For purposes of explanation, it is assumed that the second function called in the example of FIG. 1 cannot complete execution by performing the desired functionality.
According to typical prior art computer aided design applications function(A) 100 calls function(B) 120 with first function call 110. First function call 110 can be any type of function call known in the art, for example, function calls according to a C++ programming environment, or a C programming environment.
Instructions of function(B) 120 are executed until an instruction that calls function(C) 140 is executed. As a result, function call 130 is executed. Instructions of function(C) 140 are executed until some instruction cannot be executed properly. For example, an instruction may perform the function of opening a non-existent file, or a divide by zero operation, a constraint solver failure, etc.
When execution of instructions in function(C) 140 stops because an instruction cannot be complete, function(C) 140 returns a result to function(B) 120 via return 150. Return of results can be performed by any manner known in the art. Typically, when function(C) 140 cannot complete execution, the result(s) returned indicate that an error occurred, and the possible cause of the software fault.
Upon receiving error result(s) from function(C) 140, function(B) 120 cannot complete execution and similarly returns error results to function(A) 100 via return 160. Function(A) 100 thus receives two error results caused by a single error. The greater the number of function calls the greater the number of error messages that are generated based on a single error, which can be confusing and overwhelming to a user of a computer aided design tool employing such an error reporting scheme.
The multiple error messages often result from a subroutine call that returns a error result to the calling subroutine, which in turn returns its own error result along with the original error message to the corresponding subroutine. This process continues until a routine responsible for error reporting is reached. By that time, multiple error results have been generated for a single fault. The same sequence occurs for warning messages.
Another shortcoming of the prior art is that typically only the first or last message for an error is reported, which either lack the context in which the error occurred or lack sufficient detail to accurately describe the error. What is needed is an error reporting mechanism that reduces the number of error/warning messages caused by a single execution fault while providing sufficient detail for the user to understand the error/warning.